Transparent garbage collection of resources

ABSTRACT

Techniques for transparently registering non-memory resources used by a program with a garbage collector so that the non-memory resources can be freed when the program is finished using them. The techniques automatically determine from the program that the execution will use a resource and then automatically modify the program&#39;s behavior so that the resource is registered. When the program is finished with the resource, it can be determined from the registry whether the resource must be freed. In one embodiment, the technique is employed in a garbage collector for doing resource garbage collection with legacy C and C++ programs. The garbage collector locates invocations that allocate such resources in the code and modifies the code so that when it is executed, the resources are registered. The techniques can also be used to ensure that finalizers associated with objects are executed before the object is freed. In this use, the invocation of the constructor for the object is modified so that the object and its finalizer are registered. When the object is no longer in use, the garbage collector uses the registry to obtain the object&#39;s finalizer, which it executes before it frees the object. Where the object represents a resource, execution of the finalizer will free the resource.

CROSS REFERENCES TO RELATED APPLICATIONS

This patent application claims priority from U.S. provisionalapplication No. 60/076,626, Spertus, Garbage collection of resources,filed Mar. 3, 1998.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates generally to the management of the resources usedby a computer program in the course of its execution and morespecifically to the prevention of resource leaks. A resource leak occurswhen a program is finished using a resource but does not free it for useby other programs.

2. Description of the Prior Art: FIGS. 1 and 2

A program that is executing on a computer system uses resources providedby the computer system. The resources include memory and non-memoryresources such as files and input-output devices. In many cases, accessto these non-memory resources is provided by the operating system, whichitself maintains data structures representing these resources

Leaks may occur with any of these resources. Memory leaks have long beendealt with by garbage collectors, that is, programs which check formemory which was allocated by a program but is no longer being used bythe program and may therefore be freed for use by other programs. Asuccessful commercial example of a garbage collector is the GreatCircle™ garbage collector, manufactured by Geodesic Systems, Inc. Anoverview of this garbage collector was available on Feb. 22, 1999 athttp://www.geodesic.com/greatcircle/overview.html. The Great Circlegarbage collector works not only with programs specifically coded to berun with it, but also with programs that were not coded to be run withit, and can thus be used with legacy programs, that is, programs thatare still useful but cannot be economically reimplemented to takeadvantage of innovations such as garbage collectors.

Non-memory resources pose a problem for garbage collectors. FIG. 1 showswhy. The figure shows a program that is written in an object-orientedprogramming language such as C++ as the program is being executed in acomputer system. In object-oriented programming languages, the programmanipulates objects, that is, entities which belong to classes. Theclass to which an object belongs defines a fixed set of operations thatmay be performed on the class. FIG. 1 shows how such programs aretypically implemented. Code 107 for the program consists of code 111 fora main program and code 113 for the operations for the classes ofobjects which are used by main program code 111 and code 113. One set ofcode for objects of class N is shown at 115. Included in the operationsdefined for a class are a constructor operation 117, which performs theactions necessary to construct an object of the class, and a destructoroperation 119, which performs any actions that need be done before thestorage for an object of the class is freed. The destructor operation isan example of a finalizer operation, namely an operation that a garbagecollector must perform before it reclaims an object's storage.

A single object of class N is shown at 121. The object has two parts:specifiers 123 for the operations defined for its class, and the data125 upon which these operations are performed. In the case of objects ofclass N, the data includes a font descriptor, a value provided by theoperating system to specify a font used by the program. Font descriptor127 is used by operations of class N that involve functions provided byan operating system font engine, shown at 129. When given a charactercode, a size specification, and a font descriptor 121, font engine 129can generate a representation of the character of the specified size inthe specified font. In order to accelerate generation of theserepresentations, font engine 129 makes a rendering 131 of the font whichit stores in its address space 105. Once the rendering is made, fontengine 129 can find the representation by looking it up in therendering. The font descriptor and its related rendering are examples ofnon-memory resources. The rendering in particular is large, andefficient operation of the operating system requires that renderings 131be released when they are no longer required by a program. The followingdiscussion primarily concerns non-memory resources, and unless otherwiseindicated, a reference to a “resource” will be understood to be areference to a non-memory resource.

One of the functions of a class's destructor is to ensure that allresources used by the object are released when the object is destroyed.Thus, destructor 119 for objects of class N 115 includes a call to theoperating system which indicates to font engine 129 that font descriptor127 and its associated rendering 131 may be released for use by otherprograms. Of course, if the programmer forgets to expressly free object121, its destructor will never be executed and not only object 121, butalso font descriptor 127 and rendering 131 will have leaked.

As can be seen from FIG. 1, having a garbage collector detect thatobject 121 is no longer in use and freeing object 121 will not by itselfsolve the problem of the leaked non-memory resources. The garbagecollector can free object 121's memory, but since the garbage collectoris in general not in a position to know anything about object 121'sclass or about the contents of its memory, it will not executedestructor 119 when it frees object 121 's memory, and as far as fontengine 129 can determine, both font descriptor 127 and rendering 131 arestill in use.

In prior art garbage collectors, this problem has been solved byproviding registration functions that explicitly indicate to the garbagecollector that a destructor is to be executed when an object is freed.When the programmer writes a program that allocates an object for whicha destructor must be executed when the object is freed, the code thatallocates the object includes the registration function. FIG. 2 showstwo examples of such code. The first example, at 201, is written in C;the programmer has written a noisyCleanup function 203 which is to beexecuted when certain objects are freed. At 205, an object ip isallocated using the malloc function; immediately following this functioncall, at 207, the programmer has made a call to the gcDeclareFinalizerregistration function. This function, which takes the object and thecleanup function as arguments, registers the cleanup function with thegarbage collector (in this case, a Great Circle garbage collector).

The result of registration is the creation of an entry for the object ina registration table 209 maintained by the garbage collector. Eachregistration entry (RTE) 211 in the table specifies two items ofinformation: an object pointer 213, which points to the object whoseallocation resulted in creation of the entry, and finalizer pointer 215,which points to the destructor 119 for the object's class. Beforefreeing an object, the garbage collector searches registration table 209for a RTE 211 that contains a pointer 213 to the object; if it findsone, it executes the code specified by finalizer pointer 215 in theentry before it frees the object.

Continuing with FIG. 2, 217 shows how a C++ programmer would specifythat an object be registered. Because C++ is an object-orientedlanguage, the programmer must specify an object's finalizer as part ofits class definition. The #include compiler directive at 219 specifiesthat the file “gct.h” that contains the class information for theregistration operation gcCleanup be included in this file, making thename gcCleanup visible here. The statement at 221 adds gcCleanup to thedefinition of the class A and defines it for that class. For class A,inheriting from gcCleanup defines the finalizer for class A as thedestructor for class A, namely ˜A ( ), which is in turn defined to bewhatever code is written where cleanup action appears. As a result ofthis code, every time an object of class A is allocated in a programexecution, the object is registered in registration table 209, withfinalizer pointer 215 pointing to the code that does the action definedfor ˜A.

While registration solves the problem of ensuring that a garbagecollector not only prevents memory leaks, but also prevents leaks ofnon-memory resources, registration as presently practiced has twoproblems:

Since the code specifying registration must be in the program when theprogram is written, garbage collectors that are used with legacyprograms to collect garbage cannot register objects and therefore cannotexecute finalization code for the objects.

Even where the programmer is writing new code for execution with agarbage collector, the programmer must still remember to includeregistration code in the class definition for every object that requiresfinalization before the object is freed.

What is needed is a technique for making garbage collection ofnon-memory resources as automatic from the programmer's viewpoint asgarbage collection of memory already is. Such a technique would not onlymake garbage collection of non-memory resources possible with legacycode, but would also relieve the programmer of the burden of concerninghim or herself with it when writing new programs. It is an object of theinvention to provide such a technique.

SUMMARY OF THE INVENTION

The technique of the invention automatically determines by examining aprogram that the program will use the resource and then automaticallymodifies the program's behavior such that the program's execution makesan entry for the resource in a registry. When it is determined that theexecution no longer requires the resource, the entry in the registryindicates that the resource is to be released.

The technique of the invention may also be employed to ensure thatfinalizers associated with objects are executed. The techniqueautomatically determines from the program being executed that theprogram will use an object and then automatically modifies the program'sbehavior such that the program's execution makes an entry for thefinalizer in the registry. When it is determined that the execution nolonger requires the object, the entry indicates that the finalizer thatis to be executed in conjunction with freeing the object. One frequentuse of a finalizer is to free a resource associated with the object.

Modification of the behavior of the program may be done at any time upthrough the execution of the program. One way of modifying the program'sbehavior is to replace a call to a function whose execution entailsallocating an object or a resource with a call to a registrationfunction that makes the entry in the registry and then calls theoriginally-intended function.

The technique may be particularly advantageously employed in conjunctionwith a garbage collector. The garbage collector performs the actionsnecessary to modify the behavior of the program and whenever the garbagecollector frees an object that is no longer used by the program, thegarbage collector executes the object's finalizer if there is an entryfor the object in the registry.

Other objects and advantages will be apparent to those skilled in thearts to which the invention pertains upon perusal of the followingDetailed Description and drawing, wherein:

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a drawing showing an object-oriented program and the resourceleak problem;

FIG. 2 is a drawing showing prior-art object registration techniques;

FIG. 3 is a flowchart of automatic registration;

FIG. 4 is a block diagram of a garbage collector that does automaticregistration;

FIG. 5 shows the Windows PE format files and DLLs, as well as linking;

FIG. 6 shows how the garbage collector modifies the executable image;and

FIG. 7 shows how the registration code makes an entry for an object inregistration table 419 when the object's constructor is invoked.

Reference numbers in the drawing have three or more digits: the tworight-hand digits are reference numbers in the drawing indicated by theremaining digits. Thus, an item with the reference number 203 firstappears as item 203 in FIG. 2.

DETAILED DESCRIPTION

The following detailed description will begin with a conceptual overviewof automatic registration of non-memory resources for a garbagecollector and will then present a detailed description of a preferredembodiment for use with programs running under the Windows® brandoperating systems manufactured by Microsoft Corporation.

Overview: FIGS. 3 and 4

In the prior art, registration of an object for resource garbagecollection has required that the programmer specifically add code to hisprogram to do the registration. The present invention adds the codenecessary to do registration automatically, that is, without any needfor the programmer to change the program's source code. Depending on theembodiment of the invention, the code may be added at any point betweenthe time the programmer has reached a point where the source code can becompiled or interpreted through the time that the object is actuallyallocated. The code may be added to the source code in a pre-compilationstep or during compilation itself, it may be added to the object codeeither before or after linking, and it may be added to executable codeeither after loading or during execution. The code may be added in line,or it may be added in the form of an invocation of a registrationfunction. When the code is interpreted, the interpreter may add the codeto do the registration at the time the object is actually allocated orthe interpreter's code may be modified to do the registration.

FIG. 3 shows in broad overview how the code to do the registration isadded. The flowchart of FIG. 3 is executed by a program that in apreferred embodiment is a component of a garbage collector; in otherembodiments, it could be a component of a programming system for writingcode to be executed in a system that included a garbage collector oreven an stand-alone program. The program works as shown in FIG. 4. Itsearches through the code it is analyzing until it finds a function thatallocates an object for which non-memory resources are required (309);when it finds such a function, it adds registration with the garbagecollector (311) to that function; it repeats this processing, as shownby loop 307, until no more such allocation functions can be found (305),at which point the program terminates. The program is able to find thefunctions that allocate objects with non-memory resources because suchresources are represented in modem object-oriented programming systemsby object class libraries. The class of any object which uses non-memoryresources will include a constructor function which creates the objectand a destructor function which releases the non-memory resource, andthe program need only keep a list of the constructor and destructorfunctions for objects belonging to those classes. Whenever a function isfound which is on the list of constructors, registration is added to theactions performed by the function and the registration registers theobject's destructor as its finalizer. Depending on the manner in whichprograms are represented in the environment in which the programsexecute and the stage at which the registration code is inserted, theconstructor and destructor functions may be recognized by their names,by their positions in data structures, or by the pointers that representthem.

The technique shown in flowchart 301 can also be applied to programsthat are interpreted instead of compiled. With such programs, eachfunction invocation is examined as it is received in the interpreter;when a function invocation is found that matches a function on the list,the code for registration is inserted into the instruction stream. Usingthis technique, the code for registration can even be inserted when whatis being interpreted is machine instructions. Another way of achievingthe same end with an interpreter would be to have the interpreter do theregistration, instead of inserting the code into the instruction stream.

FIG. 4 shows a garbage collector 401 that has been adapted for automaticregistration of objects that use non-memory resources. Memory collectioncomponents 403 are used for garbage collecting memory; memory analyzer405 analyzes the memory currently being used by an execution of aprogram to determine which objects in the program's memory are currentlybeing used by the program. Such objects are marked and a list 407 ofmarked objects is made. Then the garbage collector scans memorybelonging to the program and uses free function 411 to free any unmarkedand therefore unused objects.

Non-memory resource collection components 413 implement automaticregistration of objects that use non-memory resources and execution ofthe finalizer functions for those objects before the objects are freed.Registration code inserter 415 is code which carries out the processingof flowchart 301. In so doing, it uses function list 416, which is alist of the constructor and destructor functions for objects that mayuse non-memory resources. The registration code inserted by registrationcode inserter 415 is seen at 417. How the registration code makes theregistration table entry for an object depends on the programmingenvironment and the point in time at which the registration code isinserted. The remaining components are registration table 419, which isan implementation of registration table 209, and registration tablereader 421, which finds an entry 211 for an object in registration table419 and then executes the function specified by finalizer pointer 215 inthe entry.

Operation of garbage collector 401 is as follows: some time prior tocompletion of allocation of an object that may use non-memory resources,registration code inserter 415 adds registration code 417 to the codefor the object's constructor. As pointed out above, the registrationcode may be added at any point from when the programmer has the code incondition for automatic processing by the programming system he or sheis using on. When an object is allocated using the constructor functionwith the added registration code, the result is an entry 211 in table419 whose finalizer pointer 215 specifies the code that needs to beexecuted to free the non-memory resources belonging to the object. Aftermemory analyzer 405 determines that the object is no longer being usedby the program, garbage collector 401 invokes registration table reader421 with a pointer to the object. Registration table reader 421 findsentry 211 for the object, and causes the function specified by finalizerpointer 215 to be executed. Registration table reader 421 may alsoinvalidate entry 211, thereby making it available to register anotherobject. The finalization function is executed sometime between the timethat memory analyzer 405 determines that the object is no longer beingused and the time that free function 411 frees the object.

Detailed Description of a Preferred Embodiment: FIGS. 5-7

The preferred embodiment which will be described in the following isintended for use with code that is to run under the Windows brandoperating system manufactured by Microsoft Corporation and with aparticular set of classes that define the objects which represent theresources. The techniques used to implement the preferred embodiment areparticular to the Windows environment and take advantage of detailedknowledge of the particular set of classes. As will be immediatelyapparent to those skilled in the art, however, these techniques orvariations on them may be employed in other programming and executionenvironments and with other sets of classes.

In the Windows brand operating systems, as in many other operatingsystems, code for utility programs that are used by many user programsis contained in one or more dynamically-linked libraries, or DLLs. Forexample, the code for the class definitions for the objects thatrepresent system resources in an object-oriented programming environmentis contained in one or more such DLLs. Similarly, the code for a garbagecollector that is to be used during execution of a program is containedin one or more such DLLs. At the beginning of execution of the program,the Windows loader dynamically combines the program with the DLLs ituses into an executable image in the memory of the computer system. Itis this executable image that is actually executed by the computersystem.

Code that is ready for execution by a Windows operating system is in theportable executable file format, or PE format. A description of thisfile format may be found in the paper, Randy Kath, The portableexecutable file format from top to bottom, 1993. The paper has beenpublished on disc 2 of the Microsoft msdn library which accompaniedMicrosoft Visual C++ 6.0 Standard Edition in 1998. FIG. 5 shows a PEformat file 503 for a program that will be executed with a garbagecollector. Included in PE file 503 is an .idata section 505, whichcontains an idata entry (IDE) 507 for each imported function that isinvoked by the program. An imported function is a function that is notcontained in the file to which the idata section 505 belongs. Allfunctions from a DLL that are invoked by a program that uses the DLL areof course imported functions. The IDE 507 identifies the importedfunction by name, that is, the information in the IDE can be used tolocate the DLL file 511 containing the function and the function withinthe DLL file. The IDE 507 also contains space 506 for a pointer to thefunction. As will be explained below, the loader adds the pointer priorto execution of the program.

IDE 507 shown in FIG. 5 contains resource constructor name 505, which isthe name used to specify resource constructor code 513 in DLL 511. Nextto name 505 is the space 506 for the pointer. DLL 511 in turn containsclass definitions for the resources provided by the operating system.The DLL files are themselves PE files, and consequently contain .idatasections 505 for calls to functions in other DLL files. All calls toimported functions are made via the IDE 507 for the function.

When program 503 is to be executed, the loader component of theoperating system links the file for the program 503 and the DLLscontaining the functions specified in the program's .idata section 505into a single executable image in the address space of the process thatwill execute the program. The executable image is shown at 515. Sincethe program is to be executed with a garbage collector, the executableimage includes at least program 503, DLL 511, and DLL 519 for thegarbage collector. Included in DLL 519 for the garbage collector areregistration code inserter 415, function list 416, and registration code417 itself. When the loader creates the executable image, it adds thepointers to the locations of the code for the imported functions in theexecutable image to the names of the functions in .idata section 505 ofPE file 503 and in the DLLs. Thus, .idata section 505 now not onlycontains RC name 509, but RC pointer 517 that points to the location ofresource constructor 513's code in the executable image.

In the preferred embodiment, when a program is to be executed with thegarbage collector, the user starts the garbage collector and the garbagecollector then starts the program. Where the program was not written forexecution with the garbage collector, the garbage collector modifies theidata sections of the executable image and its DLLs other than thegarbage collector DLL before starting the program. The modificationsreplace pointers in the idata sections 505 which point to functionswhich have consequences for garbage collection, such as memory allocateand free functions, with pointers to modified versions of thosefunctions in the garbage collector DLL. The general technique ofmodifying the idata sections that is used here is discussed in detail inthe paper ??????? [Mike—I need a bibliography reference for the .idatamodification paper you gave me.]

In the preferred embodiment, the technique of modifying the idatasection is also used by the garbage collector to ensure that objectswhich may use non-memory resources are registered in registration table419. The program 503 whose execution is to be started by the garbagecollector is linked with a specific set of DLLs containing the classdefinitions for the resources that are of interest to the garbagecollector, and function list 416 contains the names of the constructorsfor these resources. The actual modification is done by registrationcode inserter 415. Registration code inserter 415 scans the .idatasections 505 of program 503 and its DLLs other than the garbagecollector DLL in executable image 515. Whenever registration codeinserter 415 finds an IDE 507 that contains RC name 505 for one of theresource constructors, it replaces pointer 517 to the resourceconstructor with a pointer to registration code 417.

The results of the garbage collector's modifications in this regard areshown at 601 in FIG. 6. IDE 507, which formerly contained a pointer toresource constructor 503, now contains a registration code pointer 603to registration code 417 in garbage collector DLL 519. In the preferredembodiment, registration code 417 contains registration code for eachresource constructor that is of interest and registration code pointer603 points to the part of registration code 417 that does theregistration for the resource constructor indicated by resourceconstructor name 505. The same thing is done with pointers toconstructors which involve non-memory resources in all of the DLLs inthe executable image.

It should be noted here that the modification technique just describedis effective in the Windows operating system environment because allcalls to imported functions are made through IDEs 507 in idata sections505 and because the Windows operating system permits an executingprogram to modify its own executable image 515. In environments wherethere is no such restriction on calls to imported functions,registration code inserter 415 may have to find such calls in the bodyof the executable image, and in environments which prohibit theexecuting program from modifying its own executable image 515,registration code inserter 415 may have to find such calls in the DLLsprior to linking. In such a case, of course, inserter 415 would replacethe invocation by name of the resource constructor with an invocation byname of registration code 417. With all of these variations, however,what changes is not so much the technique as the area of the executableimage or the program files which needs to be searched and the time atwhich the search and replacement must be done.

Once the garbage collector has modified executable image 515 as justdescribed, it begins executing program 503. When program 503 or a DLLmakes a call to a resource constructor, the modified IDE 507 transformsthe call into a call to registration code 417. FIG. 7 shows what happenswhen registration code 417 is executed. The call to registration code417 goes to the portion 717 of the code for the resource whose objectthe resource constructor constructs. Portion 717 of the code containsboth the name of the resource constructor 505 and the name 719 of thedestructor for objects representing the resource.

The Windows operating systems include a function 721 which, when given ahandle to a DLL file and the name of a function in the file, returns thepointer to the function's location in executable image 515. Portion 717first uses OS system 721 to obtain the pointer to resource constructor513. Using this pointer, portion 717 invokes resource constructor 513,which constructs resource object 711 and returns object pointer 713 toregistration code 417. Portion 717 then uses Rdname 719 with OS function721 to obtain the pointer to the destructor function for the objec. Nowthat portion 717 has both the pointer to object 713 and the pointer todestructor 715, portion 717 makes registration table entry 211(i) forthe object and destructor. Having done so, it returns object pointer 713to program 503. From program 503's point of view, the result of theinvocation of portion 717 of the registration code is exactly the sameas if resource constructor 513 had been invoked.

It should be pointed out here that the techniques employed in thepreferred embodiment to get the information needed to replace the callsto the constructors for the relevant objects with calls to theregistration function and the information that the registration functionneeds to make the entry in registration table 419 for the object areparticular to the program execution environment provided by the Windowsoperating system. In other execution environments, other techniques maybe used to obtain the information. For example, call redirection may bedone at earlier stages in the progress of the code from source code toan executable image, or may be done upon the actual execution of thecall.

Similarly, the techniques used to obtain pointers to the constructorsand destructors may vary. For example, in the absence of an operatingsystem function that provides a pointer, the garbage collector may haveto build its own table which relates the names of constructors anddestructors to their pointers. In some programming environments, theinformation may be obtainable from the objects themselves. For example,if the constructor and destructor pointers are at fixed places in allobjects, the garbage collector could obtain them from those fixedlocations. Moreover, to the extent that the programming environmentmakes an object's class information available when the program isexecuted, the garbage collector can use the class information to obtainthe necessary pointers.

The garbage collector of the preferred embodiment is a mark and sweepincremental garbage collector. In such garbage collectors, the objectsthat are currently in use by the program are marked and then the onesthat are not in use are swept, that is, freed. The destructor for anobject may be executed at any time before the object itself is freed. Inthe preferred embodiment, the garbage collector executes the destructorsimmediately after the sweep. It does so by executing registration tablereader 421, which in a preferred embodiment takes each valid RTE 211 inturn and determines whether the object specified by object pointer 713has been marked as being in use. If it has not been so marked, tablereader 421 calls the destructor specified by destructor pointer 715 inthe entry. After the destructor has been called, table reader 421invalidates table entry 211, making it available for use by otherobjects.

Program code 503 may explicitly free objects, either because it waslegacy code that was not originally written for use with a garbagecollector or because precise control over when an object is freed isdesired. In order to deal with such programs, the garbage collector usesthe techniques just described to replace the operating system's freefunction with its own free function. This free function examinesregistration table 419 to determine whether the object being freed hasan entry 211 in the table; if it does, the free function executes theobject's destructor code. To speed up the examination of registrationtable 419, the free function may use searching techniques such ashashing.

Conclusion

The foregoing Detailed Description has described in detail the best modepresently known to the inventors of automatically registering objectsthat require destructor functions to be executed before they are freedwith a garbage collector so that the garbage collector can execute thedestructor function before it frees the object. The automaticregistration techniques disclosed herein not only free the programmer ofthe burden of including registration functions in his programs, theyalso make it possible to do resource garbage collection with legacyprograms and thereby to prevent resource leaks. It should further bepointed out that the automatic registration techniques described hereinare not limited to destructors for resources, but can be employed in anysituation where a finalizer needs to be executed before an object isfreed.

While the preferred embodiment is implemented in the environmentprovided by the Windows brand operating systems and indeed takesadvantage of certain features of that environment, it will beimmediately apparent to those skilled in the relevant arts that theautomatic registration techniques are disclosed herein are not limitedto the Windows brand operating system environment, but may be employedwith the variations necessary for the environment in any environment inwhich it is possible to determine that an execution of a program willuse a resource or an object and that the execution has ceased using theresource or object.

For all of the foregoing reasons, the Detailed Description is to beregarded as being in all respects exemplary and not restrictive, and thebreadth of the invention disclosed here in is to be determined not fromthe Detailed Description, but rather from the claims as interpreted withthe full breadth permitted by the patent laws.

What is claimed is:
 1. A method of releasing a resource used by an execution of a program in a computer system when the execution no longer requires the resource, the method comprising the steps performed by one or more other programs executing in the computer system of: automatically determining from the program that the execution will use the resource; automatically modifying the program's behavior such that the execution makes an entry for the resource in a registry; and automatically determining from the state of the execution that the execution is finished with the resource and thereupon releasing the resource when the registry so indicates.
 2. The method set forth in claim 1 wherein the step of modifying the program's behavior includes the step of: automatically modifying the program's code such that execution of the modified code results in the modified behavior.
 3. The method set forth in claim 2 wherein: the step of automatically determining from the program that the execution will use the resource includes the step of detecting an invocation of a resource providing function that provides the resource to the execution in the program; and the step of automatically modifying the program's code includes the step of modifying the code containing the invocation so that execution of the invocation is accompanied by making the entry for the resource.
 4. The method set forth in claim 3 wherein the step of modifying the code containing the invocation comprises the step of: replacing the invocation of the resource providing function with an invocation of an entry making function whose execution results in the entry being made and the resource providing function being executed.
 5. The method set forth in any one of claims 1 through 4 wherein: the step of modifying the program's behavior is done at any time through execution of the program.
 6. The method set forth in any one of claims 1 through 4 wherein: the resource is associated with an object; in the step of automatically modifying the program's code, the program's code is automatically modified so that the execution makes the entry when the object is created; and in the step of automatically determining whether the execution is finished with the resource, the execution is determined to be finished with the resource when the execution is no longer using the object.
 7. The method set forth in claim 6 wherein: the execution of the program takes place in an environment which includes a garbage collector; and in the step of automatically determining whether the execution is finished with the resource, the garbage collector determines that the execution is no longer using the object and releases the resource prior to freeing the object.
 8. The method set forth in claim 7 wherein: the garbage collector performs the steps of automatically determining from the program that the execution will use the resource and automatically modifying the program's behavior.
 9. The method set forth in claim 8 wherein: the garbage collector performs the steps of automatically determining from the program that the execution will use the resource and automatically modifying the program's behavior at any time through execution of the program.
 10. A device that stores data, the device being characterized in that: the device contains code which, when executed in a computer system, performs the steps of the method set forth in claim
 8. 11. A device that stores data, the device being characterized in that: the device contains code which, when executed in a computer system, performs the steps of the method set forth in any one of claims 1 through
 4. 12. A method of executing a finalizer associated with an object when an execution of a program in a computer system no longer requires the object, the method comprising the steps performed by one or more other programs executing in the computer system of: automatically determining from the program that the execution will use the object; automatically modifying the program's behavior such that that the execution makes an entry for the finalizer in a registry; and automatically determining from the state of the execution that the execution is finished with the object and from the entry that the finalizer is to be executed and thereupon executing the finalizer in conjunction with freeing the object.
 13. The method set forth in claim 12 wherein the step of modifying the program's behavior includes the step of: automatically modifying the program's code such that execution of the modified code results in the modified behavior.
 14. The method set forth in claim 13 wherein: the step of automatically determining from the program that the execution will use the object includes the step of detecting an invocation of an object creation function that creates the object; and the step of automatically modifying the program's code includes the step of modifying the code containing the invocation so that execution of the invocation is accompanied by making the entry for the finalizer.
 15. The method set forth in claim 14 wherein the step of modifying the code containing the invocation comprises the step of: replacing the invocation of the object creating function with an invocation of an entry making function whose execution results in the entry being made and the object creating function being executed.
 16. The method set forth in any one of claims 12 through 15 wherein: the step of modifying the program's behavior is done at any time through execution of the program.
 17. The method set forth in any one of claims 12 through 15 wherein: the execution of the program takes place in an environment which includes a garbage collector; and in the step of automatically determining whether the execution is finished with the object, the garbage collector determines that the execution is no longer using the object and executes the finalizer prior to freeing the object.
 18. The method set forth in claim 17 wherein: the garbage collector performs the steps of automatically determining from the program that the execution will use the object and automatically modifying the program's behavior.
 19. The method set forth in claim 18 wherein: the garbage collector performs the steps of automatically determining from the program that the execution will use the object and automatically modifying the program's behavior at any time through execution of the program.
 20. A device that stores data, the device being characterized in that: the device contains code which, when executed in a computer system, performs the steps of the method set forth in claim
 18. 21. A device that stores data, the device being characterized in that: the device contains code which, when executed in a computer system, performs the steps of the method set forth in any one of claims 12 through
 15. 22. A method of automatically registering a resource used by an execution of a program in a computer system for release when the execution no longer requires the resource, the method comprising the steps performed by one or more other programs executing in the computer system of: automatically determining from the program that the execution will use the resource; and automatically modifying the program's behavior such that that the execution makes an entry for the resource in a registry, the entry being used when the execution is finished therewith to determine that the resource is to be released.
 23. The method set forth in claim 22 wherein the step of modifying the program's behavior includes the step of: automatically modifying the program's code such that execution of the modified code results in the modified behavior.
 24. The method set forth in claim 23 wherein: the step of automatically determining from the program that the execution will use the resource includes the step of detecting an invocation of a resource providing function that provides the resource to the execution in the program; and the step of automatically modifying the program's code includes the step of modifying the code containing the invocation so that execution of the invocation is accompanied by making the entry for the resource.
 25. The method set forth in claim 24 wherein the step of modifying the code containing the invocation comprises the step of: replacing the invocation of the resource providing function with an invocation of an entry making function whose execution results in the entry being made and the resource providing function being executed.
 26. The method set forth in any one of claims 22 through 25 wherein: the step of modifying the program's behavior is done at any time through execution of the program.
 27. The method set forth in any one of claims 22 through 25 wherein: the resource is associated with an object; and in the step of automatically modifying the program's code, the program's code is automatically modified so that the execution makes the entry when the object is created.
 28. The method set forth in claim 27 wherein: the execution of the program takes place in an environment which includes a garbage collector; and the garbage collector performs the steps of automatically determining from the program that the execution will use the resource and automatically modifying the program's behavior.
 29. The method set forth in claim 28 wherein: the garbage collector performs the steps of automatically determining from the program that the execution will use the resource and automatically modifying the program's behavior at any time through execution of the program.
 30. A device that stores data, the device being characterized in that: the device contains code which, when executed in a computer system, performs the steps of the method set forth in claim
 28. 31. A device that stores data, the device being characterized in that: the device contains code which, when executed in a computer system, performs the steps of the method set forth in any one of claims 22 through
 25. 32. A method of automatically registering a finalizer associated with an object for execution when a program's execution in a computer system no longer requires the object, the method comprising the steps performed by one or more other programs executing in the computer system of: automatically determining from the program that the execution will use the object; and automatically modifying the program's behavior such that that the execution makes an entry for the finalizer in a registry, the entry being used when the execution is finished with the object to determine that the finalizer is to be executed in conjunction with freeing the object.
 33. The method set forth in claim 32 wherein the step of modifying the program's behavior includes the step of: automatically modifying the program's code such that execution of the modified code results in the modified behavior.
 34. The method set forth in claim 33 wherein: the step of automatically determining from the program that the execution will use the object includes the step of detecting an invocation of an object creating function; and the step of automatically modifying the program's code includes the step of modifying the code containing the invocation so that execution of the invocation is accompanied by making the entry for the finalizer.
 35. The method set forth in claim 34 wherein the step of modifying the code containing the invocation comprises the step of: replacing the invocation of the object creating function with an invocation of an entry making function whose execution results in the entry being made and the object creating function being executed.
 36. The method set forth in any one of claims 32 through 35 wherein: the step of modifying the program's behavior is done at any time through execution of the program.
 37. The method set forth in any one of claims 32 through 35 wherein: the execution of the program takes place in an environment which includes a garbage collector; and the garbage collector performs the steps of automatically determining from the program that the execution will use the object and automatically modifying the program's behavior.
 38. The method set forth in claim 37 wherein: the garbage collector performs the steps of automatically determining from the program that the execution will use the object and automatically modifying the program's behavior at any time through execution of the program.
 39. A device that stores data, the device being characterized in that: the device contains code which, when executed in a computer system, performs the steps of the method set forth in claim
 37. 40. A device that stores data, the device being characterized in that: the device contains code which, when executed in a computer system, performs the steps of the method set forth in any one of claims 32 through
 35. 41. A garbage collector that automatically executes a finalizer associated with an object, the object being allocated during execution of a program and the finalizer being executed in conjunction with freeing the object, the garbage collector comprising: a registrar that registers the object in a registry of objects requiring execution of finalization code; a program modifier that automatically modifies the program prior to execution such that allocation of the object causes the registrar to register the object in the registry; and a registry reader that executes the finalizer in conjunction with freeing the object's memory when the registry so indicates, whereby the program need not be written for execution with the garbage collector.
 42. The garbage collector set forth in claim 41 wherein: when the object is allocated, the program executes a constructor function for the object; the program modifier detects an invocation of the constructor function and replaces the invocation of the constructor function with an invocation of the registrar; and the registrar invokes the constructor function in conjunction with registering the object.
 43. The garbage collector set forth in any one of claims 41 through 42 wherein: the program modifier modifies the program at any time through execution of the program.
 44. The garbage collector set forth in any one of claims 41 through 42 wherein: the program modifier modifies the program after the program is compiled.
 45. The garbage collector set forth in any one of claims 41 through 42 wherein: the program modifier modifies the program before the program is compiled.
 46. The garbage collector set forth in any one of claims 41 through 42 wherein: the object represents a non-memory resource; creation of the object at least potentially allocates the resource; and the finalizer frees the allocated resource.
 47. A device that stores data, the device being characterized in that: the device contains code which, when executed in a computer system, implements the garbage collector set forth in any one of claims 41 through
 42. 